Skip to content

[ES-1436915] Add additional null check for connection-context#810

Merged
gopalldb merged 27 commits into
mainfrom
gopalldb/threads
Apr 25, 2025
Merged

[ES-1436915] Add additional null check for connection-context#810
gopalldb merged 27 commits into
mainfrom
gopalldb/threads

Conversation

@gopalldb
Copy link
Copy Markdown
Collaborator

Description

Add additional null check for connection context in TelemetryHelper. To clarify, this is a no-op change as we already handle null checks in further methods in downstream implementation. This change just makes it future proof for any further changes which may ignore null check in any of further business logic.

Testing

Ran all unit tests

Additional Notes to the Reviewer

@github-actions
Copy link
Copy Markdown

Please ensure that the `NEXT_CHANGELOG.md` file is updated with any relevant changes.  
If this is not necessary for your PR, include this in the PR body:

```
NO_CHANGELOG=true
```

and rerun the workflow.

@jayantsing-db
Copy link
Copy Markdown
Collaborator

Not needed because the null checks exist in the later execution flow when logs are being exported. If we introduce more null checks, the issue at hand is masked more deeply which is inappropriate

.exportEvent(telemetryFrontendLog);
// Though we already handle null connectionContext in the downstream implementation,
// we are adding this check for extra sanity
if (connectionContext != null) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should introduce this weird ad-hoc check somewhere deep in the code when we are actually exporting the logs. This is happening already. So the PR is a no-op

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we are already doing that. It is just that to make this future proof, where we accidently add dependency on connectionContext in any downstream logic and breaking the functionality. Telemetry is common to all executions. In current impl you're right that this is a no-op.

@gopalldb
Copy link
Copy Markdown
Collaborator Author

Not needed because the null checks exist in the later execution flow when logs are being exported. If we introduce more null checks, the issue at hand is masked more deeply which is inappropriate

Telemetry should not block any critical executions. It is okay to mask nulls here. Also, null checks happen in other multiple sub-methods downstream, but this makes the check at a single entry point.

@gopalldb gopalldb requested a review from jayantsing-db April 25, 2025 07:29
Copy link
Copy Markdown
Collaborator

@jayantsing-db jayantsing-db left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline

.setEntry(new FrontendLogEntry().setSqlDriverLog(telemetryEvent));
TelemetryClientFactory.getInstance()
.getTelemetryClient(
connectionContext, DatabricksThreadContextHolder.getDatabricksConfig())
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we check DatabricksConfig too? DatabricksThreadContextHolder.getDatabricksConfig

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed for authenticated client. Added the check there.

@gopalldb gopalldb merged commit f657c50 into databricks:main Apr 25, 2025
15 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants